SD33. 솔트 없이 일방향 해쉬 함수 사용 — 사용자별 난수 솔트로 치환

원본 항목: Part 2-3. 암호화 계열 — 14. 솔트 없이 일방향 해쉬 함수 사용 CWE-759 repo 폴더: sd33_nosalt/ (빌드·실행은 §3-1) 목표 시간: 1회차 12분 / 2회차 7분 / 3회차 5분 SD32에서 “해시로 저장”까지는 왔다. 이 드릴은 그다음 함정 — 같은 패스워드는 항상 같은 해시라는 사실 자체가 취약점이라는 걸 보여준다.

이 드릴의 문서 구성 (SD01~SD58 공통)

① 요구사항서 — 어떤 코드가 뚫려 있고, 무엇을 만드나. ② pseudo code 템플릿 — Bad 와 Good 의 뼈대이고, 회차마다 가린다. ③ 테스트 코드 — 공격은 막히고 정상은 통과해야 끝이다. ④ 자주 하는 실수 ⑤ 모범답안 — 맨 뒤에 접어 둔다.

변형 A/B/C 는 같은 치환 규칙을 다른 소재로 다시 치는 것이다.

---

0. 이 드릴로 체화할 것

- unsigned hash_no_salt_bad(const char *pw) { return toy_hash(pw); }
+ unsigned hash_with_salt_good(const char *pw, unsigned salt) {
+     char buf[128];
+     snprintf(buf, sizeof(buf), "%u:%s", salt, pw);
+     return toy_hash(buf);
+ }

해시는 “되돌릴 수 없다”가 아니라 “미리 계산해 두면 찾을 수 있다”이다. 솔트가 사전 계산(레인보우 테이블)을 막는다.

회차별 진행

회차	변형	보는 것	순서
1회차	A 두 사용자의 동일 패스워드	① 요구사항서 ② pseudo code 전체	1. Bad 를 그대로 쳐서 취약점을 관찰한다. 2. Good pseudo 를 한 줄씩 코드로 바꾼다. 3. ③ 테스트를 실행한다.
2회차	B 솔트를 해시값과 함께 저장	① 요구사항서 ② pseudo code 의 번호와 제목만 (Level 2)	1. Bad 를 치고 취약점을 확인한다. 2. 번호만 보고 Good 을 쓴다. 3. ③ 테스트를 실행한다.
3회차	C 반복 횟수(iteration) 개념 도입	① 요구사항서만	1. ③ 테스트를 먼저 읽는다. 2. 백지에서 Bad 부터 Good 까지 재현한다.

1회차에 막히면 같은 변형을 한 번 더 친다. 3회차를 통과하면 A 를 백지로 다시 친다.

---

1. 요구사항서

1-A. 변형 A — 두 사용자의 동일 패스워드

여러 사용자의 패스워드를 해시로 저장한다.

• 서로 다른 사용자가 같은 패스워드를 쓰더라도, 저장된 해시값은 서로 달라야 한다.

함수

unsigned hash_no_salt_bad(const char *pw);
unsigned hash_with_salt_good(const char *pw, unsigned salt);

공격 입력표

상황	Bad 결과	이유
alice, bob이 둘 다 hunter2 사용	완전히 같은 해시값	솔트가 없어 입력이 같으면 출력도 같다 — 레인보우 테이블 대조 한 번으로 둘 다 뚫린다
같은 상황(Good, 서로 다른 솔트)	서로 다른 해시값	사전 계산된 테이블이 무력화된다

1-B. 변형 B — 솔트를 해시값과 함께 저장

“솔트는 비밀이 아니다”라는 원칙에 따라, 저장 레코드를 {salt, hash} 구조체로 만들어 검증 시 저장된 솔트를 그대로 재사용하는 흐름을 완성

1-C. 변형 C — 반복 횟수(iteration) 개념 도입

toy_hash 를 N번 연쇄로 적용하는 “반복” 개념을 추가해, 대량 추측 공격에 걸리는 시간을 늘리는 원리를 체감(PBKDF2의 핵심 아이디어)

---

2. pseudo code 템플릿 — 보고 쳐서 익힌다

사용법 변형별로 아래 pseudo code 를 소스 파일에 주석만 복사한다. 코드는 주석을 보고 내가 쓴다. 다 쓰면 [ ] 를 x 로 바꾼다. 막히면 §5 모범답안(A)의 해당 단계만 본다.

2-A. hash_with_salt_good — Level 1 (1회차, 전부 본다)

먼저 Bad 를 그대로 쳐서 §3 의 test_bad_is_vulnerable 이 통과하는지(= 실제로 뚫리는지) 확인한다. 그다음 Good 을 쓴다.

unsigned hash_no_salt_bad(const char *pw)
{
    /* 1. return toy_hash(pw)   ← 같은 패스워드는 항상 같은 해시 */
}
 
unsigned hash_with_salt_good(const char *pw, unsigned salt)
{
    /* [ ] 1. 지역변수
     *        char buf[128] */
 
    /* [ ] 2. 솔트를 앞에 붙여 문자열을 만든다
     *        snprintf(buf, sizeof(buf), "%u:%s", salt, pw) */
 
    /* [ ] 3. return toy_hash(buf)   ← 해시 함수는 그대로 */
}

2-B. hash_with_salt_good — Level 2 (2회차, 번호와 제목만 본다)

unsigned hash_with_salt_good(const char *pw, unsigned salt)
{
    /* [ ] 1. 지역변수 */
 
    /* [ ] 2. 솔트를 앞에 붙여 문자열을 만든다 */
 
    /* [ ] 3. return toy_hash(buf)   ← 해시 함수는 그대로 */
}

2-C. hash_with_salt_good — Level 3 (3회차, 백지)

unsigned hash_with_salt_good(const char *pw, unsigned salt)
{
    /* 아무것도 안 본다.
     * §1 요구사항서와 §0 의 치환 규칙만 보고 친다.
     *
     * 막히면 아래만 찾아본다.
     *   - 솔트는 알고리즘 교체가 아니라 **해시 입력** 을 바꾸는 것
     *   - `toy_hash` 는 SD32 와 같다
     */
}

막혔을 때 찾는 순서

1. 컴파일 에러가 나면 에러 문구를 본다. unknown type name / implicit declaration 이면 include 누락이다.
2. man 3 <함수> 를 연다. SYNOPSIS 맨 위의 #include 를 확인한다.
3. 로직이 막히면 §3 테스트의 기대값을 먼저 읽는다. 공격 입력표(§1)와 테스트가 답이다.
4. 그래도 안 되면 모범답안의 해당 단계 하나만 본다.

---

3. 테스트 코드 — 이게 통과하면 끝

sd33_nosalt/src/salted_hash.h
sd33_nosalt/src/salted_hash.c
sd33_nosalt/test/test.c

시험 구조는 고정이다 (SD01~SD58 공통)

1. Bad 가 실제로 뚫린다. 이 시험이 실패하면 Bad 를 잘못 옮겨 적은 것이다.
2. Bad 도 정상 입력은 처리한다.
3. Good 이 같은 공격을 막는다.
4. Good 이 정상 입력까지 막지 않는다. (과잉 차단 없음)

3-A. 변형 A 시험 — 이 형태를 고정한다

#include <stdio.h>
#include "salted_hash.h"
 
static int g_fail = 0;
#define T_TRUE(cond, msg) \
    do { if (!(cond)) { g_fail++; \
        printf("  X %s:%d %s\n", __func__, __LINE__, msg); } } while (0)
 
static void test_bad_is_vulnerable(void)
{
    unsigned h1 = hash_no_salt_bad("hunter2");
    unsigned h2 = hash_no_salt_bad("hunter2");
    T_TRUE(h1 == h2,
        "Bad는 두 사용자가 같은 패스워드를 쓰면 완전히 같은 해시가 나와야 한다(레인보우테이블 취약점 재현)");
}
 
static void test_good_blocks_precompute(void)
{
    unsigned h1 = hash_with_salt_good("hunter2", 111);
    unsigned h2 = hash_with_salt_good("hunter2", 222);
    T_TRUE(h1 != h2,
        "Good은 같은 패스워드라도 솔트가 다르면 해시도 달라져야 한다(사전 계산 공격 무력화)");
}
 
static void test_good_normal(void)
{
    unsigned h1 = hash_with_salt_good("hunter2", 111);
    unsigned h2 = hash_with_salt_good("hunter2", 111);
    T_TRUE(h1 == h2, "같은 패스워드+같은 솔트는 항상 같은 해시가 나와야 한다(검증 가능해야 함)");
}
 
int main(void)
{
    test_bad_is_vulnerable();
    test_good_blocks_precompute();
    test_good_normal();
    printf(g_fail ? "FAIL %d\n" : "PASS\n", g_fail);
    return g_fail ? 1 : 0;
}

3-B · 3-C. 변형 B / C 시험

3-A 와 같은 4종 구조에서 호출 함수와 입력만 바꾼다.

변형 B — 솔트를 해시값과 함께 저장

입력	Bad	Good
저장 레코드 {salt, hash}	솔트가 없다	저장된 솔트를 재사용해 검증
올바른 비밀번호	통과	통과

변형 C — 반복 횟수(iteration) 개념 도입

입력	Bad	Good
toy_hash 를 N 번 연쇄 적용	한 번 계산	N 번 계산 (추측 비용 증가)
N = 1	같은 값	같은 값

3-1. 빌드와 실행 (Makefile, gcc)

Makefile 은 템플릿 체화 드릴 README 와 같은 파일이다. recipe 줄은 반드시 탭으로 들여쓴다.

공통 Makefile (gcc)

# ~/cdrill/Makefile  (템플릿 체화 드릴과 같은 파일)
# 사용법:  make D=sd01_sqli V=main SRC="common/mock_db.c sd01_sqli/src/sql_auth.c sd01_sqli/test/test.c"
CC       := gcc
CFLAGS   := -Wall -Wextra -Werror -std=c11 -D_POSIX_C_SOURCE=200809L -g -DUNIT_TEST -Icommon -I$(D)/src
SAN      := -fsanitize=address,undefined -fno-omit-frame-pointer
LDLIBS   ?= -pthread
 
D        ?= d1_pure
V        ?= main
SRC      ?= $(D)/src/$(V).c $(D)/test/test_$(V).c
BIN      := build/$(D)_$(V)
 
all: run
 
build:
	@mkdir -p build
 
$(BIN): build $(SRC)
	$(CC) $(CFLAGS) $(SAN) $(SRC) $(LDLIBS) -o $(BIN)
 
run: $(BIN)
	@echo "── run ──────────────────────────────"
	@./$(BIN)
 
check: $(BIN)
	@./$(BIN) && echo "PASS" || (echo "FAIL"; exit 1)
 
clean:
	rm -rf build
 
.PHONY: all run check clean build

실행 명령이다.

make D=sd33_nosalt V=main SRC="sd33_nosalt/src/salted_hash.c sd33_nosalt/test/test.c"

• 마지막 줄이 PASS 이고 경고 0 이면 통과다.
• -Werror 때문에 컴파일이 안 되면 테스트 이전에 코드를 고친다.

참고: Makefile 없이 순수 gcc 로 실행

mkdir -p build
gcc -Wall -Wextra -Werror -std=c11 -D_POSIX_C_SOURCE=200809L -g -DUNIT_TEST \
    -Icommon -Isd33_nosalt/src \
    -fsanitize=address,undefined -fno-omit-frame-pointer \
    sd33_nosalt/src/salted_hash.c sd33_nosalt/test/test.c \
    -pthread -o build/sd33_nosalt_main
./build/sd33_nosalt_main

---

4. 자주 하는 실수

실수	왜 문제인가
test_good_normal 을 빼먹음	솔트를 섞었다고 해시 함수가 “무작위”가 되면 안 된다. 검증 시점에는 같은 솔트로 같은 결과가 나와야 로그인이 가능하다. 이 시험이 그걸 보증한다
솔트를 매번 새로 생성해서 검증 시 다른 솔트를 사용	저장할 때 쓴 솔트를 검증할 때도 그대로 재사용해야 한다(변형 B에서 {salt, hash} 쌍 저장으로 해결)
솔트 값을 아주 좁은 범위(0~9)에서만 고름	후보가 적으면 솔트별로 레인보우 테이블을 10개만 만들면 되므로 방어 효과가 줄어든다. 실전에서는 128비트급 난수 솔트를 쓴다(SD35와 연결)

---

5. 모범답안 (변형 A)

다 치고 나서 열 것 — salted_hash.h / salted_hash.c

#ifndef SALTED_HASH_H
#define SALTED_HASH_H
unsigned hash_no_salt_bad(const char *pw);
unsigned hash_with_salt_good(const char *pw, unsigned salt);
#endif

#include <stdio.h>
#include "salted_hash.h"
 
static unsigned toy_hash(const char *s)
{
    unsigned h = 5381;
    while (*s) h = ((h << 5) + h) + (unsigned char)(*s++);
    return h;
}
 
unsigned hash_no_salt_bad(const char *pw) { return toy_hash(pw); }
 
unsigned hash_with_salt_good(const char *pw, unsigned salt)
{
    char buf[128];
    snprintf(buf, sizeof(buf), "%u:%s", salt, pw);
    return toy_hash(buf);
}

눈여겨볼 점: hash_with_salt_good 은 해시 함수 자체(toy_hash)를 바꾸지 않았다 — 입력값 앞에 솔트를 붙였을 뿐이다. 솔트는 알고리즘 교체가 아니라 “무엇을 해시하는가”를 바꾸는 문제라는 걸 이 한 줄이 보여준다.

---

관련 노트

• 시큐어코딩 체화 드릴 목록
• 이전: SD32. 패스워드 평문 저장
• 다음: SD34. 부적절한 RSA 패딩